One Network to rule them all

14-15 Mar, Netnod18

Christian Adell

Networking nowadays

Challenges

  • Scalability
  • Containerisation
  • Distributed Systems
  • Multi-platform
  • High Performance applications
  • Efficiency

Are we ready?

  • Multi-vendor with legacy devices not well-suited for automation
  • There is a lot of new things to learn
  • Vendor trainings aren’t (weren’t) focused on this
  • Automation amplify everything (including mistakes)
  • Usually, not close to developers, to the business

And most of the times, we don’t know where to start from...

How can we approach it?

  • APIs everywhere, your network devices should support them
  • Use Data Models, they will help you translate your will
  • Take advantage of the information your network is providing
  • Don't fear dynamic infrastructure
  • Some coding skills will be needed
  • Validate, validate and validate again

Start by solving simple problems... keeping applications on your line of sight

A brief story of a network service

Typical IT ecosystem

How the network looks like

Downsides

  • By default, inter/intra platform communications use Internet which is not (always) the most performant, secure and cheapest communication channel
  • Manual network provisioning doesn’t work in terms of speed and reliability
  • Prone to errors and lack of consistency
  • Some communications still need network layer security (no TLS)

We tried to solve all in one

... and we failed

(non-technical) Lessons learned

  • Think as your users will do
  • Get feedback as soon as possible, iterate!
  • The solution should flexible enough to accommodate several underlying solutions
  • Evaluate current needs case-per-case (capability, performance, cost, etc.)
  • Apply Pareto Rule, focus on solving most urgent first

Then, we created a network service

New goal

Requirements

  • Easy onboarding / selfserve
  • Users should be autonomous to handle connections
  • Abstract all network details from users, and pick the best option in every case
  • Support several providers/platforms
  • Offer a secure service
  • Continuous monitoring of connection status

Assumptions

  • Mgmt-API users will be authenticated through a SSO / Token
  • Permissions to manipulate others' network infrastructure
  • External APIs to integrate with
  • Consistent address plan (less pain)

Actual implementation

  • A rest API
  • A distributed asynchronous architecture
  • Extensible modules to talk with underlying network services
  • Running on dynamic infrastructure (IaaS, PaaS, SaaS)
  • Infrastructure as Code and Continous Integration and Deployment

Architecture

Entities

  • Service: Abstract container of Providers and Resources, owned by OKTA users
  • Provider: Environment/Platform where Resources are deployed
  • Resource: A network element defined by the network address (CIDR)
  • Connection: Bidirectional link between Resources

Demo

Scenario

If your browser doesn't support the embbeded video format, you can get it from here

Why to use this?

  • You don't care about underlying network details
  • You always use the best possible network solution
  • You have one API to handle any network solution
  • You are notified about your connections' health
  • You need an out-of-the-box multiple platform connectivity
  • You get visibility about your network dependencies

Takeaways

  • Don’t be afraid of going out of your comfort zone
  • At some point, you will need to join pieces
  • Learning coding will give you superpowers
  • Adopting a DevOps approach will speed up your business (and career)
  • Networking is a key skill in IT, bring it close to the business

Thanks for your attention

Q/A

FAQs

  • Any plan to opensource it?
  • What's the difference with service mesh?